Currently, standards (SQL3) (ISO and ANSI standards) for a database language (SQL) have commenced. An ADT (Abstract Data Type) is one of the main features of the SQL3 standards. The ADT is a data type defined by the user, adopting an object oriented concept. Operations of the ADT are defined by the user as a method (or a function or a procedure). The ADT can have a complex structure. Operations of the ADT (ie. its accompanying functions) are included in the definition as ADT functions. The definition of the ADT prescribes specifications of attributes (groups) and operations of a group prescribing their operations.
An ADT function for generating a new instance of the ADT is a constructor function. An access to an attribute of the ADT is made by using an observer function while a modification is made by a mutator function. The SQL itself can be used in the definition of such a function. Such a function can also be defined by using a general programming language such as C. The definition written in the programming language is then compiled into an external module which can then be specified. Relations between such modules and the ADT functions are described in ADT definition statements for defining the ADT. A module is the format of an internal expression of an ADT function. As a general implementation, pieces of ADT definition information are controlled by a database management system as dictionary information as is the case with table definitions.
FIG. 12 is a diagram showing a typical configuration of a database management system having a mechanism for calling a module related to an ADT function.
In a relational database management system, the SQL is a non-procedural language. Therefore, first of all, a user inquiry 2 is analyzed to determine an internal processing procedure prior to execution. Before the user inquiry 2 is executed, a preprocess processing 10 analyzes the user inquiry and determines an internal processing procedure. As an embodiment of the internal processing procedure, an execution procedure command package 30 is used. In the case of a user inquiry 2 with an ADT function described therein, ADT defining information 200 stored in a dictionary is referenced in the analysis of the user inquiry 2 and embedded module calling information 40 on a related embedded module 90 for implementing the ADT function is added to the execution procedure command package 30.
In execution control during the execution of the user inquiry 2, a DB (database) access function 70 in charge of the actual DB access processing is used in accordance with the execution procedure command package 30 in order to process the user inquiry 2. If execution of the ADT function is requested in the execution procedure command package 30, the related embedded module 90 is called as shown by an arrow. The calling of the related embedded module 90 is based on the embedded module calling information 40.
As an example, the processing of the following SQL statement is explained. SELECT NAME, AGE (MOTHER) FROM CLASS.sub.-- A WHERE AGE (MOTHER)&lt;25
The above SQL statement is a request to retrieve names (on a NAME column) of a table CLASS.sub.-- A of mothers (which is a MOTHER-column attribute) younger than 25 years along with the ages of the mothers. The data type of the MOTHER column is a person type which has an age returning AGE ADT function defined for it. The AGE ADT function is implemented by invoking a .sub.-- p.sub.-- person.sub.-- calculate embedded module.
In the user inquiry processing for the above SQL statement, a piece of line data is retrieved and the AGE ADT function is applied to the data on the MOTHER column. Namely, the.sub.-- p.sub.-- person.sub.-- calculate embedded module is called to evaluate the WHERE clause. The result of the evaluation is used to determine whether or not the name is fetched from the NAME column. Then, the processing is continued to the next piece of line data. As described above, the conventional ADT function is positioned as an evaluation function for ADT data of one line in an SQL statement. Thus, in the conventional database management system, processing is carried out on pieces of data sequentially one piece after another.
As described above, an operation defined by the user can be implemented by merely specifying an ADT function for the operation in an SQL statement. That is to say, the specification of the ADT function in an SQL statement produces a module calling trigger on which the operation is executed. In the case of the method described after the SELECT clause in the above SQL statement, the ADT function is applied to lines sequentially one after another which are selected by the WHERE clause. As for the phrase described after the WHERE clause, the ADT function is applied for generating timing or a module calling trigger for returning values (the name of a mother and her age) which is determined by a conditional judgment, that is, an age below 25 years. To view it from a different standpoint, at any rate, there is no module calling trigger for executing an ADT function defined by the user but the explicit description of the ADT function in an SQL statement.
On the other hand, for evaluation (search) peculiar to an ADT or high speed evaluation (search), the use of index data dedicated for the ADT is conceivable. This index data used specially for the ADT is not limited to the B-tree index data generally used as a means for speeding up a search operation in the ordinary database management system. Instead, a variety of information groups or the like required for implementing an ADT function are included.
If dedicated index data is used in the ADT function, however, a change in ADT data makes it necessary to update the dedicated index data accordingly. Not only is it necessary to operate dedicated index data in accordance with a description of an ADT function in an SQL statement, but the dedicated index data must also be manipulated in the event of an operation such as INSERT and DELETE to process ADT data without using an ADT function, on a module calling trigger such as a system start or a system completion and on a module calling trigger such as a transaction start or a transaction completion. In addition, the execution of an embedded module for implementing a built-in search (evaluation) function by using dedicated index data does not necessarily involve processing of pieces of data sequentially one after another as in the internal processing of the conventional ADT function. It is also possible to think of dedicated index data which summarizes data satisfying a certain search (evaluation) condition and returns the summarized data as a set for the condition. In this case, it is not necessary to execute the corresponding embedded module as many times as pieces of data in the database to be evaluated (to find out if the data meets a condition). Instead, the corresponding embedded module needs to be executed only once. The amount of overhead for the execution, that is, the amount of overhead for calling the embedded module can thus be reduced.
If an attempt is made to implement a function using dedicated index data in the ADT frame of the present state of the art, the following problems arise:
(1) Since execution of the ADT function is the only module calling trigger for maintaining dedicated index data, the number of module calling triggers is not sufficient. PA0 (2) The internal processing of the ADT function is limited to processing of a piece of data.